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Bandwidth  Usage  of  the  Collaborative  Tool: 
Microsoft  NetMeeting  V2.0 


Executive  Summary 

The  ADF  is  making  increased  use  of  inexpensive  commercial-off-the-shelf  (COTS) 
software  to  provide  electronic  support  to  commanders.  One  area  from  which  the  ADF 
stands  to  gain  immediate  benefit  is  the  use  of  COTS  software  to  support  distributed 
work  practices.  DSTO's  Command  Support  System  Group  (CSSG)  under  the 
"Research  On  Collaborative  Knowledge  Systems"  (ROCKS)  task,  ADF  97/061  has  been 
investigating  the  suitability  of  commercial  applications  to  support  collaborative 
planning  in  a  distributed  headquarters  environment.  CSSG  is  considering  the  use  of 
Microsoft  NetMeeting  to  provide  support  for  distributed  meetings.  This  report 
investigates  the  ability  of  NetMeeting  to  operate  successfully  in  a  bandwidth 
constrained  environment. 

The  report  shows  that  NetMeetings  audio  and  video  conferencing  features  can  be 
used  effectively  at  bandwidth's  as  low  as  32  kbps  making  the  product  viable  for  use 
over  man  portable  satellite  systems.  It  finds  that  the  NetMeeting  systems  policy, 
which  is  an  optional  software  component  used  by  the  system  administrator  to  manage 
software  configuration,  successfully  constrains  average  bandwidth  consumption  but 
does  not  guarantee  that  peaks  in  bandwidth  demand  will  not  exceed  the  available 
capacity.  We  also  found  that  simple  measures,  such  as  ensuring  that  the  video  is 
always  optimised  for  speed,  drastically  reduce  bandwidth  consumption  with  no 
impact  on  utility. 

The  report  also  examines  the  use  of  the  T.120  conferencing  standards  on 
NetMeetings  data  conference  facilities.  We  found  that  the  sequence  in  which 
participants  join  a  data  conference  has  a  major  impact  on  the  data  conferencing 
bandwidth  requirements.  The  report  examines  ways  to  ensure  that  data  conferences 
are  always  set  up  to  ensure  the  most  efficient  use  of  wide  area  network  bandwidth. 
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1.  Introduction 


Two  innovations  in  the  provision  of  electronic  support  to  commanders  provide  stimuli 
for  this  report.  Increasingly,  commercial-off-the-shelf  (COTS)  products  are  being 
adopted  without  change  for  use  in  support  of  military  command  and  control  - 
including  in  the  tactical  arena.  Secondly,  the  command  support  environment  is 
attempting  to  introduce  collaborative  planning  tools  including  distributed  tools 
between  headquarter  locations.  Accordingly,  there  is  an  increasing  desire  to  field 
commercial  collaborative  tools,  such  as  personal  (workstation)  video  conferencing, 
shared  whiteboards  and  shared  applications. 

DSTO's  Command  Support  System  Group  (CSSG)  has  been  developing  prototype 
collaborative  planning  tools,  which  are  increasingly  being  adapted  for  use  in  a 
distributed  headquarters  environment  and  between  different  headquarters.  The 
current  work  named  "Research  On  Collaborative  Knowledge  Systems"  (ROCKS)  is 
based  on  COTS  products,  specifically  Lotus  Notes.  In  adapting  the  original  ROCKS 
from  a  system  which  operates  on  a  single  local  area  network  (LAN)  to  one  which 
operates  between  sites,  CSSG  is  considering  the  integration  of  Microsoft  NetMeeting. 
The  choice  of  this  software  is  further  justified  as  the  ROCKS  development  is  integral  to 
DSTO  support  to  the  experimental  Deployable  Joint  Force  Headquarters  (experimental 
DJFHQ  or  exDep)  based  on  HQ  1st  Division  which  had  independently  decided  on 
NetMeeting  as  a  tool  for  collaborative  meetings. 

COTS  products  such  as  NetMeeting  are  often  developed  for  LAN  environments 
where  bandwidth  is  relatively  easy  to  provide,  or  for  low  rate  telephone  modem 
operation.  The  nature  of  the  bandwidth  demands  of  such  software  when  used  in  a 
tactical  military  environment  of  shared,  low  bandwidth  links  has  not  been  determined. 

2.  Aim 


This  report  seeks  to  characterise  the  bandwidth  usage  of  the  collaborative  tool: 
Microsoft  NetMeeting  V2.0. 


3.  Background 


3.1  Operational  Scenario 

It  is  expected  that  tools  such  as  NetMeeting  will  be  used  on  the  LAN  provided  within 
headquarters  where  bandwidth  usage  will  not  be  a  substantial  problem.  A  more 
challenging  scenario  for  its  use  will  be  between  headquarters  where  communications 
over  the  wide  area  network  (WAN)  will  be  more  limited.  This  will  be  particularly  so 
for  the  DJFHQ  where  the  link  between  the  initially  lodged  headquarters  and  the  yet  to 
be  deployed  main  body  may  be  limited  to  32  kbps  over  manportable  satellite  facilities. 
In  such  a  case  the  tool  will  provide  a  critical  link  between  the  two  elements  during  the 
conduct  of  initial  planning  of  the  deployment  with  one  or  perhaps  two  computers  in 
the  advance  party  linking  back  to  staff  in  the  old  location  (usually  barracks). 

DJFHQ  staff  have  advised  that  even  in  such  a  limited  capacity  scenario,  the  links 
would  interconnect  internet  protocol  (IP)  routers.  Such  an  approach  ensures  that  the 
capacity  could  be  shared  between  multiple  applications  running  at  the  deployed  site  as 
well  as  providing  seamless  interconnection  into  the  wider  Defence  intranet. 
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3.2  NetMeeting  Use  of  the  Internet  Protocols 

While  NetMeeting  can  operate  directly  between  two  hosts  via  serial  line  or  dial-up 
modem,  the  operational  scenario  would  indicate  the  major  use  will  be  over  a  shared  IP 
network. 

The  internet  protocols  (more  usually  known  as  TCP/IP  from  Transmission  Control 
Protocol/ Internet  Protocol),  has  been  developed  using  a  layered  approach  (see  general 
data  communications  texts  such  as  Tanenbaum  [1]  for  a  more  complete  description). 
The  IP  layer  provides  best  effort  service  to  get  data  packets  from  the  originating  host  to 
the  destination  host.  This  provides  the  internetworking  layer  upon  which  the  well 
known  TCP  layer  provides  reliable  end  to  end  connections.  Less  well  known  is  the 
User  Datagram  protocol  (UDP).  This  protocol  operates  at  the  same  layer  as  TCP, 
however  provides  a  best  effort  datagram  service  over  IP.  NetMeeting  uses  both  TCP 
as  well  as  UDP  for  interconnection  services. 

Since  TCP  provides  a  reliable  end  to  end  connection,  this  is  the  appropriate 
protocol  for  the  exchange  of  data  which  must  get  through,  regardless  of  time  delay. 
NetMeeting  thus  employs  TCP  for  the  exchange  of  NetMeeting  control  messages  and 
for  sharing  screen  information  such  as  shared  whiteboard  and  shared  applications. 

UDP  provides  a  best  effort  datagram  service,  and  this  is  the  appropriate  protocol 
for  the  exchange  of  real  time  information  where  timeliness  is  more  important  than 
completeness  of  information.  For  applications  such  as  NetMeeting' s  video  and  audio, 
loss  of  some  data  is  not  critical  as  there  is  a  continuous  flow  of  fresh  information  to 
follow  any  losses.  The  TCP  mechanisms  for  reliability  of  transfer  mean  that  the 
network  delay  experienced  by  the  data  can  vary  significantly  as  lost  data  is 
retransmitted.  Such  variation  in  network  delay  makes  interactivity  via  video  and 
audio  difficult  and  so  UDP  is  the  preferred  protocol  for  these  applications. 

Below  the  IP  layer  is  the  physical  layer.  In  the  case  of  the  scenario  considered,  this 
is  likely  to  be  the  Point  to  Point  Protocol  (PPP).  Just  as  TCP  or  UDP  adds  overheads 
(headers/ footers)  to  user  data,  which  in  turn  is  packaged  by  IP  headers,  PPP  adds  a 
protocol  overhead.  The  impact  of  these  overheads  will  be  discussed  in  detail  later  in 
this  report. 

3.3  NetMeeting  Use  of  International  Telecommunications  Union 
Standards 

NetMeeting  has  adopted  a  number  of  International  Telecommunications  Union  (ITU) 
standards  within  its  architecture.  The  key  motivation  behind  the  use  of  such  standards 
is  to  improve  interoperability  between  NetMeeting  and  similar  systems.  The  two  key 
standards  that  impact  on  the  bandwidth  usage  characteristics  are  ITU  T.120  and  ITU 
H.323.  As  stated  in  the  NetMeeting  Resource  Kit  [2]: 

The  ITU  T.120  standard  is  made  up  of  a  suite  of  communication  and 
application  protocols  developed  and  approved  by  the  international 
computer  and  telecommunications  industries.  These  protocols  enable 
developers  to  create  compatible  products  and  services  for  real-time, 
multipoint  data  connections  and  conferencing.  T.120-based  applications 
enable  many  users  to  participate  in  conferencing  sessions  over  different 
types  of  networks  and  connections. 

Depending  on  the  type  of  T.120  product,  they  can  make  connections, 
transmit  and  receive  data,  and  collaborate  using  compatible  data 
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conferencing  features,  such  as  application  sharing,  conferencing 
whiteboard,  and  file  transfer.  Microsoft  and  more  than  100  other  major 
companies  support  the  development  of  products  and  services  using  the 
T.120  standard. 

Significant  to  this  study,  T.120  impacts  on  the  distribution  of  traffic  between 
participants  when  a  conference  involves  more  than  a  point  to  point  connection.  This  is 
discussed  in  more  detail  in  Section  5.3  Impact  of  Conference  Topology  .  T.120,  because 
of  its  control  nature  and  the  need  for  guaranteed  distribution  of  information  employs 
TCP  rather  than  UDP  in  IP  networks. 

The  second  standard  has  considerably  more  impact  on  the  nature  of  NetMeeting 
traffic.  NetMeeting  has  adopted  the  ITU  H.320  family  of  standards  for  audio-visual 
conferencing.  H.320  offers  a  range  of  optional  voice  and  video  coding  standards  but 
typically  NetMeeting  will  opt  for  the  low  rate  options  -  H.263  for  video  coding.  The 
coding  standards  within  H.320  have  significant  impact  on  bandwidth  usage  which, 
when  understood,  explains  the  nature  of  the  bandwidth  usage  of  audio  and  video 
conferencing. 

Video  coding  is  a  process  of  digitising  moving  images  and  processing  the  digital 
data  so  that  it  can  be  reduced  to  a  scale  capable  of  being  moved  over  die  transmission 
media.  The  data  rate  can  be  reduced  by  two  principal  approaches  -  by  taking 
advantage  of  redundancy  of  the  information  within  a  single  frame  (ie  intraframe 
coding)  and  redundancy  between  frames  (ie  interframe  coding).  Significant  areas  of 
an  image  exhibit  the  same  or  similar  pixel  value  (dot  brightness)  across  the  frame  thus 
offering  intraframe  redundancy.  More  significantly,  large  portions  of  a  frame  will 
often  be  quite  similar  to  portions  of  previous  frames,  thus  offering  interframe 
redundancy.  Video  conferencing  standards  (such  as  H.263)  typically  send  periodic 
frames  coded  only  in  an  intra  fashion  followed  by  a  number  of  frames  wheie  the 
difference  between  the  frame  and  a  previous  frame  is  coded  (interframe  coding).  If  an 
image  is  highly  complex  (i.e.  with  much  detail),  the  intraframe  coding  generates  a 
large  number  of  bits,  conversely  flat  images  produce  fewer.  Similarly,  video  with  little 
movement  generates  fewer  bits  in  interframe  coding  than  video  with  large  activity. 

The  consequence  of  this  is  that  the  bit  rate  out  of  the  coding  process  can  be  highly 
variable.  A  constant  bit  rate  video  device  copes  with  this  variability  by  buffering  the 
output  of  the  raw  coder.  The  high  bit  rate  periods  tend  to  fill  the  buffer,  while  the  low 
bit  rate  periods  tend  to  empty  the  buffer.  The  buffer  cannot  be  too  big  otherwise 
excessive  coding  delay  (ie  time  taken  for  the  coded  representation  to  be  generated  and 
sent  to  the  receiver)  will  disturb  interactivity.  If  the  buffer  becomes  too  full,  the  coder 
can  only  resort  to  reducing  quality  of  the  coded  representation  to  reduce  the  bit  rate. 
Consequently,  the  visual  quality  of  a  constant  bit  rate  video  coder  system  is  variable. 

In  contrast  to  a  constant  bit  rate  coder,  the  NetMeeting  implementation  of  H.263, 
especially  when  used  on  a  large,  variable  capacity  media  such  as  a  local  area  network, 
is  not  constrained  to  be  constant  bit  rate.  As  a  consequence  its  demands  on  the 
communications  system  will  burst  up  and  down  depending  on  the  nature  of  the  video 
being  coded.  Any  user  control  over  bandwidth  usage  of  NetMeeting  will  control  the 
average  capacity  used,  but  this  may  not  impact  on  the  peak  demands  of  the  system. 

3.4  NetMeeting  Facilities 

NetMeeting  is  a  collaborative  meeting  support  tool  which  has  a  limited  conferencing 
capability  allowing  two  users  at  a  time  to  exchange  audio  and  video.  NetMeeting  also 
provides  the  ability  for  several  users  to  share  a  whiteboard  and/ or  Windows 
applications,  eg  Microsoft  Word  or,  across  a  network.  In  any  NetMeeting  conference 
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several  or  all  users  may  be  sharing  applications  but  only  two  of  the  participants  may 
be  using  the  video  conferencing  features  at  any  point.  NetMeeting  does,  however, 
provide  facilities  to  switch  video  conferencing  between  participants,  i.e.  broadcast  of 
the  video  from  one  to  many  users  is  not  supported.  To  achieve  multiple  sessions, 
multiple  meetings  are  required. 

3.5  NetMeeting  Use  of  System  Policies  to  Restrict  Bandwidth  Usage 

System  policies  are  an  optional  feature  of  the  Windows  95  and  Windows  NT  operating 
systems.  They  give  systems  administrators  the  ability  to  standardise  and  control 
access  to  operating  system  and  application  configuration  settings. 

The  NetMeeting  Resource  Kit  [2],  which  is  available  as  an  optional  download  from 
the  Microsoft  web  site,  contains  a  system  policy  which  allows  the  systems 
administrator  to  set  default  values  and  restrict  user  access  to  a  comprehensive  range  of 
NetMeeting  options.  During  our  testing  the  system  policy  was  installed  and  the  policy 
option  "Set  limit  for  audio/video  throughput"  was  tested.  This  option  gives  the 
systems  administrator  the  ability  to  set  an  average  bandwidth  consumption  rate  for 
audio  and  video  traffic  on  a  specific  computer.  It  is  important  to  note  that  this  option 
does  not  set  a  hard  limit  for  throughput,  rather  it  is  an  average  rate  for  audio  and 
video.  Setting  this  option  has  no  limiting  effect  on  data  traffic,  eg  file  transfer  or 
whiteboard  traffic. 

The  NetMeeting  Resource  Kit  [2]  Chapter  10  "Controlling  Bandwidth  with 
NetMeeting  System  Policies"  gives  an  overview  of  the  actual  mechanisms  used  to  limit 
the  audio/ video  bandwidth. 


4.  Test  Set  up 


4.1  Configuration  One 

The  configuration  for  the  initial  one-to-one  tests  consisted  of  the  following  equipment: 

•  Two  IBM  Thinkpad  760XD  Pentium  150  MMX  fitted  with  Compro  D-Cam  Digital 
cameras  and  PCMCIA  10/100Mb/s  Zircom  CE3  ethernet  adaptor  running  at 
10Mb/ s. 

•  Two  Sparcstation  5s  (Burke  and  Canb)  fitted  with  FORE  Systems  ATM  adaptors 
acting  as  network  gateways. 

•  One  10Mb/  s  shared  ethernet  hub. 

The  ATM  cards  fitted  to  the  network  gateways  provided  a  Classical  IP  over  ATM 
connection  which  was  used  to  simulate  a  WAN.  The  bandwidth  of  the  WAN  was 
modified  during  experiments  to  represent  both  LAN  rates  and  WAN  values  which  the 
ADF  would  reasonably  expect  to  encounter  in  a  deployed  environment. 

4.2  Variables  Tested  With  Configuration  One 

The  following  software  settings  where  used  during  testing.  A  brief  description  of  each 
setting  is  included  in  Table  1  below.  Full  details  on  NetMeeting  options  may  be 
obtained  from  the  NetMeeting  Resource  Kit  [2]. 
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TableJ^  NetMeeting  Options 


Option 

_ „ _ I. 

Settings  used  during  testing 

— i - — - - 

Description 

NetMeeting  -  audio 

On  or  Off 

Controls  the  sending  of  audio. 

NetMeeting  -  video 

On  or  Off 

Controls  the  sending  of  video. 

NetMeeting  -  video 

quality 

Speed  or  Quality 

Sliding  scale  which  optimises  the  video 
transmission  for  speed  of  delivery  or  quality 
of  the  image.  During  testing  optimisation 
was  for  either  full  speed  or  full  quality. 

NetMeeting  System  Policy 
Option  - 

"Set  limit  for  audio/video 
throughput" 

None,  256kbps,  32kbps, 
28kbps 

Sets  the  average  bit  rate  for  audio  and  video. 

Gateway  Operating 

System  -  WAN  bandwidth 

10Mb/ s,  256kbps,  32kbps 

Used  to  set  simulated  WAN  connection  rate. 

This  combinations  of  controls  lead  to  a  matrix  of  test  options  described  in  table  2. 


Table  2.  Test  Plan  for  Configuration  One 


No 

Network 
Constraint 
(10  Mb/s) 

256  k 
Network 

32  k 

Network 

video  high 

quality 

5 

5A 

5B 

video  fast 

6 

6A 

6B 

32  k  limit 
profile 


video  high 

quality 

7 

7A 

7B 

video  fast 

8 

8A 

8B 

28  k  limit 
profile 


video  high 

quality 

7C 

video  fast 

The  actual  WAN  bandwidth  available  to  NetMeeting  during  testing  was  slightly 
less  that  the  settings  shown  in  Tables  1  and  2.  This  is  because  the  use  of  Classical  IP 
over  ATM  introduces  a  small  additional  framing  overhead  of  8  bytes  per  IP  packet.  As 
this  overhead  is  relatively  small  it  was  not  taken  into  consideration  when  assigning 
bandwidth  values  to  the  WAN  connection. 

4.3  Configuration  Two 

The  configuration  used  to  test  the  effect  of  conference  topology  on  bandwidth  was: 

•  Three  IBM  Thinkpad  760XDPentium  150  MMX  fitted  with  Compro  D-Cam  Digital 
cameras  and  PCMCIA  10/100Mbp/s  Zircom  CE3  ethernet  adaptor  running  at 
lOMb/s. 

•  One  Sparcstation  5  used  to  run  the  network  monitoring  software. 

•  One  10Mb/ s  shared  ethernet  hub. 
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4.4  Monitoring  Software 

The  monitoring,  processing  and  analysis  of  the  NetMeeting  experiments  was  carried 
out  in  a  three  stage  process  using  software  appropriate  for  each  stage. 

The  Unix  snoop  utility  was  used  to  capture  the  details  of  packets  exchanged 
between  the  NetMeeting  processes.  The  snoop  program  promiscuously  monitors 
packets  and  records  for  each  packet,  time  of  arrival,  type  of  packet  (TCP,  UDP  etc), 
TCP/UDP  port  number  and  payload  length.  The  output  of  the  program  can  be  to  the 
screen  or,  more  typically  to  a  special  snoop  format  file  for  later  off-line  analysis.  The 
program  allows  the  user  to  filter  to  consider  traffic  only  from  a  particular  source, 
destination,  port  number  or  packet  type.  For  this  stage,  snoop  was  monitoring  all 
traffic  from  the  system  under  test.  More  detailed  filtering  was  conducted  in  the  next 
stage. 

A  DSTO  developed  program  snoop Jbps  took  a  text  file  generated  from  snoop  for 
processing.  Snoop_bps  collated  the  output  of  snoop  into  activity  in  each  second  of  time. 
The  payloads  were  totalled  to  determine  the  effective  user  bit  rate  being  offered  each 
second.  A  second  calculation  was  made  to  determine  the  bit  rate  being  offered  to  the 
network.  IP,  TCP  or  UDP  headers  for  each  were  considered.  In  addition,  it  was 
assumed  that  the  packets  would  be  transmitted  over  the  wide  area  as  PPP  and 
appropriate  header  overheads  were  factored  in.  The  output  of  this  program  was  a  text 
file  suitable  for  input  into  the  analysis  phase. 

4.5  Data  Analysis 

The  analysis  phase  was  conducted  using  Excel  spreadsheets.  For  each  test  Snoop_bps 
was  used  to  produce  a  set  of  files  for  the  sending  and  the  receiving  ends  of  the  link. 
Each  set  was  composed  of  a  file  containing  the  TCP,  audio  and  video  traffic.  All  six  of 
these  files  were  loaded  into  a  single  spreadsheet.  This  data  was  then  used  to  generate 
two  types  of  graph.  The  first  is  an  area  graph  showing  the  distribution  of  information 
by  its  type  ie  TCP,  audio,  video.  The  second  is  a  simple  line  graph  showing  the  total 
number  of  bits  per  second  (bps)  transmitted  and  optionally  the  total  bps  received.  It  is 
important  to  note  that  all  graphs  in  this  report  are  not  drawn  to  the  same  scale,  to 
assist  the  reader  all  X  axes  are  labelled  in  hours:minutes:seconds. 

In  addition  to  the  graphs,  the  average  bandwidth  and  peak  bandwidth  usage  in 
bps  was  calculated.  The  average  bandwidth  is  based  on  audio  and  video  traffic  only 
and  did  not  include  any  TCP  traffic.  Both  average  and  peak  bandwidth  were  always 
calculated  for  the  period  of  time  that  both  audio  and  video  was  being  transmitted.  An 
approximation  of  the  amount  of  information  lost  during  periods  when  the  application 
was  offering  more  traffic  than  the  network  could  transport  was  also  calculated. 

5.  Test  Results 

5.1  Introduction  to  Results 

The  NetMeeting  Resource  Kit  [2]  identifies  a  range  of  factors  which  will  influence 
bandwidth  consumption;  among  these  are  the  choice  of  hardware  (camera  and  CPU 
type),  and  the  choice  of  operating  system  (Windows  95  vs  Windows  NT).  It  is 
therefore  important  for  the  reader  to  note  that  results  obtained  during  testing  are 
specific  to  the  hardware/ software  configuration  tested. 
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The  amount  of  movement  in  the  video  is  also  an  important  factor  which  affects 
bandwidth  consumption.  During  our  testing  approximately  one  third  of  the  test 
cameras  field  of  view  was  unintentionally  obstructed  by  the  back  of  the  laptop,  thus 
the  amount  of  movement  in  our  picture  was  reduced.  In  addition  we  were  positioned 
so  that  there  was  little  or  no  movement  behind  the  subject.  It  would  be  reasonable  to 
assume  that  if  the  product  was  deployed  in  a  different  environment  such  as  a  busy 
command  centre  the  product  would  use  more  bandwidth. 

5.2  UDP  and  IP  Protocol  Overhead 

As  discussed  earlier  in  section  3.3,  NetMeeting  utilises  the  IP  suite.  The  majority  of 
traffic  generated  by  NetMeeting  is  UDP,  i.e.  video  and  audio  data  contained  in  a  UDP 
datagram  which  is  in  turn  encapsulated  by  an  IP  packet.  For  the  purposes  of  our 
discussion  on  protocol  overheads  we  shall  ignore  the  TCP  traffic  as  the  volume 
generated  is  small  when  compared  to  the  volume  of  UDP  traffic,  see  Figure  1. 


Data  Received  at  Burke  During  Test  5 
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Figure  1 

As  can  be  seen  from  Figure  1  the  overhead  for  audio  traffic  is  quite  noticeable  and 
remains  constant,  whilst  at  this  scale  the  overhead  for  video  traffic  is  undetectable. 
This  result  is  to  be  expected  as  audio  traffic  is  composed  of  many  small  UDP  packets 
whilst  the  video  traffic  is  sent  in  fewer  larger  UDP  packets.  Figure  2  is  a  two  minute 
sample  taken  from  the  same  data  starting  at  11:34:38. 
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2  Minutes  of  Data  Received  at  Burke  During  Test  5 
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Figure  2 

Throughout  the  remainder  of  this  report  we  will  only  consider  the  gross  data 
amount  which  includes  the  TCP/UDP  and  IP  protocol  overheads. 


5.3  Impact  of  Conference  Topology 

The  following  extract  from  the  NetMeeting  2.0  Resource  Kit  [2]  gives  an  overview  of 
the  role  of  conference  topologies  in  NetMeeting: 


The  T.120  architecture  supports  several  topologies  that  define  how  users 
connect  to  a  conference  and  transmit  data  during  the  conference.  The  following 
diagram  illustrates  three  common  topologies:  star,  daisy-chain,  and  cascaded. 
These  topologies  represent  the  types  of  connections  typical  of  NetMeeting  2.0 
conferences. 
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The  first  node  to  place  a  conference  call  always  becomes  the  top  provider  or 
controlling  node,  under  the  T.120  architecture  this  node  is  then  responsible  for 
coordinating  and  synchronising  the  conference.  The  following  extract  from  the 
NetMeeting  2.0  Resource  Kit  [2]  describes  how  the  topology  is  formed: 

Data  flows  according  to  the  conference  topology,  which  is  determined , by  how 
each  connection  in  the  conference  is  established  ("who  calls  who").  For 
example,  in  the  diagram,  the  following  order  of  calls  establishes  the  conference 

topology: 

*  A  (top  provider)  initiates  calls  to  B  and  C. 

-  Then,  B  calls  D  and  E  (or  D  and  E  each  call  B). 

«  C  calls  F  and  G  (or  F  and  G  each  call  C). 

A 


There  is  only  one  top  provider  in  a  conference.  After  the  top  provider  (A)  is 
established,  that  computer  remains  the  top  provider  throughout  the  confeience. 
Note  that  two  conferences  cannot  be  joined  together.  Therefore,  if  C  called  F  and  G 
first,  it  would  not  be  possible  for  them  to  join  the  conference  with  A,  B,  D,  and  E. 

During  data  conferencing,  if  B  shared  an  application  with  the  other  conference 
participants,  data  would  flow  simultaneously  to  the  adjoining  connections  (A,  D, 
and  E).  Then,  data  would  continue  to  flow  outward  to  the  remaining  connections. 
Also,  any  two  connections  within  the  conference  can  initiate  audio  and  video 
conferencing.  NetMeeting  enables  audio  and  video  switching,  so  that  participants 
can  switch  the  pair  sharing  audio  and  video. 

If  B  hangs  up  or  is  removed  from  the  conference,  D  and  E  are  also  removed.  D  and 
E  may  remain  conferenced  together,  though,  if  they  were  connected  with  audio 
and  video  in  the  original  session.  D  and  E  would  not  have  data  conferencing, 
however,  because  this  function  is  removed  when  B  hangs  up. 

We  make  two  observations  from  this  information,  firstly  that  the  transfer  of  audio 
and  video  information  between  two  nodes  is  point  to  point  and  not  affected  by  the 
conference  topology.  We  tested  this  using  configuration  two  with  three  computers  on 
the  same  network  segment,  snoop  was  used  to  collect  and  analyse  the  data.  We  found 
that  regardless  of  the  conference  topology,  audio  and  video  information  always  flowed 
point  to  point. 

The  second  observation  is  that  in  a  low  bandwidth  environment  the  conference 
topology  will  have  a  significant  effect  on  data  transfer.  For  example  if  we  had  two 
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sites  connected  by  a  WAN  connection,  say  Canberra  and  Brisbane  with  two  users  at 
each  site  that  wished  to  share  a  map  via  the  whiteboard,  we  could  establish  a 
connection  by  the  following  sequence: 

User  A  at  Brisbane  calls  user  B  at  Brisbane.  Later,  users  C  and  D  in  Canberra  join 
the  call  by  calling  user  A  in  Brisbane.  We  can  see  from  Figure  3  that  this  topology 
will  result  in  inefficient  use  of  the  WAN  bandwidth  as  any  changes  made  to  the 
map  by  user  D  will  first  be  sent  to  user  A  and  then  back  across  tire  WAN  to  user  C. 


Figure  3 


A  simple  rule  can  be  established  to  ensure  that  WAN  bandwidth  is  used  efficiently, 
if  you  wish  to  data  conference  with  people  at  a  remote  site  you  must  first  check  to  see 
if  anyone  at  your  site  is  already  in  the  conference  you  wish  to  join,  if  they  are  you  call 
them  if  not  call  the  person  you  wish  to  speak  to  at  the  remote  site.  By  following  this 
rule  the  WAN  bandwidth  consumption  will  always  be  minimised. 

5.4  Summary  of  Results 

Detailed  results  of  the  trials  are  at  Appendix  One.  Key  points  to  draw  from  the  trials 
are: 

•  Bandwidth  requirements  from  the  audio  connection  in  NetMeeting  is  constant  at 
about  10.5  kbps. 

•  Bandwidth  requirement  from  the  video  connection  in  NetMeeting  is  substantially 
greater  and  very  peaky. 

•  When  unconstrained,  NetMeeting  capacity  requirements  average  about  50  -60  kbps 
but  peak  around  120  - 130  kbps. 

•  Routers  routinely  provide  buffers  to  overcome  short  periods  of  congestion.  Large 
buffers  prevent  losses  -  especially  welcome  for  TCP  connections,  but  will  cause 
large  delays,  and  delay  variation,  for  real  time  communications  such  as  voice  and 
video. 

•  The  NetMeeting  policy  control  provides  good  controls  over  the  average  capacity 
consumed  by  NetMeeting,  but  does  not  constrain  peak  requirements  which  can 
overwhelm  the  link  capacity. 
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•  Providing  the  system  manager  allows,  NetMeeting  offers  a  user  control  to  set  video 
quality  to  "Fastest  Video";  this  substantially  reduces  the  capacity  requirements  of 
NetMeeting  with  little  reduction  in  picture  quality. 

6.  Conclusions 

NetMeetings  audio  and  video  conferencing  features  can  be  used  successfully  at 
network  rates  as  low  as  32  kbps.  By  taking  simple  steps  such  as  always  setting  video 
quality  to  fastest,  users  can  dramatically  decrease  the  bandwidth  that  NetMeeting 

The  different  aspects  of  NetMeeting  communications  call  for  differing  qualities  of 
service  (e  g.  voice  and  video  seek  low  delay  and  low  delay  variation)  but  this  is  not 
normally  supported  on  an  IP  network.  Some  support  is  becoming  available  with 

advanced  routers.  . 

When  using  the  data  conferencing  features  of  NetMeeting  the  manner  m  which  a 
NetMeeting  conference  call  is  set  up  has  an  appreciable  effect  on  bandwidth 
utilisation.  Users  with  a  poor  understanding  of  how  different  conference  topologies 
affect  bandwidth  could  inadvertently  double  the  required  WAN  bandwidth. 
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Appendix  A:  Detailed  Results 

1.1  Introduction 

The  combinations  of  controls  lead  to  a  matrix  of  test  options  described  in  table  3. 


Table  3.  Test  Plan  for  Configuration  One 
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1.2  Test  5  Series 

The  results  from  tests  5  are  shown  at  Figures  4  and  5.  The  configuration  for  this  test 
was  high  quality  video,  no  system  policy  constraints  and  a  lOMb/s  WAN  connection. 
The  results  show  two  characteristics  which  are  typical  of  NetMeeting  traffic.  Firstly 
audio  traffic  is  more  consistent  in  bandwidth  demand  than  video  traffic  as  can  be  seen 
from  Figure  4  which  shows  the  distribution  of  traffic  sent  during  test  5  by  traffic  type. 
We  can  also  see  from  this  graph  that  the  peaky  nature  of  the  overall  traffic  is  being 
predominantly  caused  by  the  video  traffic,  this  is  not  surprising  given  NetMeetings  use 
of  H.320  standards. 
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Figure  4 

Figure  5  shows  a  comparison  of  the  data  sent  and  received  during  test  5.  We  can 
see  from  this  graph  that  the  volume  of  traffic  arriving  at  Burke,  the  receiving  end,  is 
almost  identical  to  the  traffic  departing  Canb.  It  does  however  appear  that  some  data 
is  being  lost  during  the  highest  traffic  peaks.  It  is  more  likely  that  the  apparent  loses 
during  the  peaks  are  due  to  network  latency,  i.e.  large  packets  sent  in  one  second  being 
received  in  the  next  second. 


Figure  5 
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The  average  bandwidth  consumption  for  NetMeeting  when  both  audio  and  video 
traffic  were  being  sent  during  test  5  was  54753  bps  and  the  peak  bandwidth  was 
122672  bps.  Figure  6  shows  the  results  from  test  5a.  The  configuration  for  test  5a  was 
almost  identical  to  that  for  test  5  except  that  the  WAN  connections  bandwidth  was 
limited  to  256kbps.  The  average  bandwidth  consumption  when  sending  audio  and 
video  traffic  was  58090  bps  and  the  peak  bandwidth  was  118768  bps.  As  we  would 
expect  these  figures  are  similar  to  the  results  from  test  5.  We  can  conclude  from  these 
figures  that  even  with  audio  and  video  options  in  their  most  network  intensive  mode 
the  product  does  not  consume  more  that  140kbps  of  bandwidth  in  a  point  to  point 
video  conference. 


Comparison  of  Data  Sent  and  Received  During  Test  5a 
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Figure  6 


Test  5b  is  also  identical  to  test  5  &  5a  except  that  the  WAN  connections  bandwidth 
is  limited  to  32kbps.  In  Figure  7  we  can  see  quite  clearly  the  effect  of  the  constrained 
WAN  bandwidth,  when  the  Canb  end  is  sending  audio  only,  all  traffic  is  getting 
through.  However  as  soon  as  video  is  turned  on  at  14:19:33  the  traffic  offered  jumps 
well  above  the  available  bandwidth  and  information  loss  occurs.  The  average  traffic 
offered  whilst  both  audio  and  video  are  on  was  131016  bps  and  the  average  load 
received  at  Burke  for  the  same  period  was  48279  bps.  The  information  loss  for  the 
period  was  49%. 


15 


DSTO-TR-0605 


Comparison  of  Data  Sent  and  Received  During  Test  5b 
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Figure  7 

Figure  7  also  shows  the  buffering  provided  by  the  routers  in  the  network,  we  can 
see  from  the  graph  that  Canb  stoped  sending  video  at  14:28:33  and  that  Burke 
continued  to  receive  more  data  than  Canb  was  offering  for  another  40  seconds,  for 
approximately  the  next  3  minutes  the  traffic  received  remains  unstable  before  settling 
down  to  the  familiar  audio  pattern  at  14:32:03.  The  presence  of  the  buffer  resulted  in 
an  apparent  latency  of  about  20  seconds  when  both  video  and  audio  were  being  sent. 

It  is  hardly  surprising  given  the  results  obtained  during  this  test  that  the  video 
conferencing  features  of  NetMeeting  where  unusable.  Video  quality  was  so  bad  that 
you  could  just  identify  the  presence  of  a  person's  head  and  audio  was  extremely 
difficulty  to  understand.  This  test  is  a  graphic  illustration  of  the  fact  that  NetMeeting 
does  not  automatically  adjust  its  settings  to  suit  the  bandwidth  available. 

1.3  Test  6  Series 

Figure  8  shows  the  results  from  test  6.  The  configuration  for  this  test  was  fast  video,  no 
system  policy  constraints  and  a  10Mb/  s  WAN  connection.  The  results  indicate  that 
using  the  user  control  to  change  the  video  quality  to  "Fastest  Video"  has  a  dramatic 
effect  on  bandwidth  consumption.  The  average  bandwidth  consumption  when  both 
audio  and  video  traffic  are  being  sent  during  test  6  is  15943  bps.  This  figure  is  much 
smaller  than  the  53820  bps  average  we  obtained  for  test  5  where  the  video  quality  was 
high.  The  peak  bandwidth  generated  by  the  sender  for  test  6  was  36576  bps  compared 
to  122672  bps  for  test  5.  Test  6  also  appears  to  be  more  stable  in  terms  of  output  than 
test  5,  in  test  6  a  peak  in  video  traffic  occurs  approximately  every  20  seconds.  The 
quality  of  the  picture  received  was  subjectively  little  changed  from  the  "Highest 
Quality"  video  opted  for  previously. 


16 


DSTO-TR-0605 


Figure  8 


Figure  9  shows  the  results  for  test  6b.  The  configuration  for  this  test  was  identical 
to  test  6  except  that  the  WAN  connection  was  limited  to  32kbps.  Given  the  low 
average  traffic  and  small  traffic  peaks  of  test  6  it  is  not  surprising  that  test  6b  has 
produced  very  similar  results.  The  average  bandwidth  generated  when  both  audio 
and  video  traffic  is  being  sent  during  test  6b  is  15731  bps  and  the  peak  bandwidth 
generated  by  the  sender  is  33296  bps.  The  overall  quality  of  video  and  audio  was  quite 
good  during  this  test. 


Figure  9 
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1.4  Test  7  Series 

The  results  for  test  7  are  shown  at  figure  10.  The  configuration  for  this  test  was  high 
quality  video,  32kbps  system  policy  constraint  and  a  lOMb/s  WAN  connection. 
Comparing  the  results  from  this  test  with  test  5  we  find  that  setting  the  system  policy 
to  constrain  output  to  32kbps  has  reduced  the  average  bandwidth  consumption  when 
both  audio  and  video  traffic  is  being  sent  from  the  test  5  value  of  53820  bps  to  31879 
bps. 
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Figure  10 

We  can  see  from  figure  10  that  the  traffic  is  constantly  peaking  above  the  32kbps 
average  value  set  by  the  system  policy.  Whilst  this  has  no  appreciable  effect  in  test  7, 
because  traffic  is  not  constrained  by  the  WAN  connection,  it  does  have  an  effect  in  test 
7b  when  the  WAN  is  constrained  to  32kbps  as  shown  in  Figure  11.  This  diagram  and 
Figure  12,  which  is  a  two  minute  slice  of  data  sent  by  Canb  broken  down  by  traffic 
type,  show  that  the  video  traffic  is  being  sent  in  bursts.  Returning  again  to  figure  11 
we  see  that  the  information  received  at  Burke  is  much  smoother  hovering  around 
25kbps  this  is  due  to  network  buffering  occurring  at  the  Canb  gateway. 
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Figure  11 


Figure  12 


1.5  Test  8  Series 

Figure  13  shows  the  results  for  Test  8.  The  configuration  for  this  test  was  fast  video, 
32kbps  system  policy  constraint  and  a  10Mb/  s  WAN  connection.  As  we  would  expect 
the  results  for  this  test  are  similar  to  those  for  test  6  as  even  without  a  profile  constraint 
NetMeeting  used  less  than  32kbps  when  optimised  for  fast  video. 
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